Many phases of modern electronic design are performed with computer aided design (CAD) tools or electronic design automation (EDA) systems. An EDA system typically receives the high level behavior descriptions of the IC device and translates this high-level design language into netlists of various levels of abstraction using a computer synthesis process. A netlist describes interconnections of nodes and components on the chip and includes information of circuit primitives such as transistors and diodes, their sizes and interconnections, for example.
Many electronic systems include both hardware components and associated software that run with or on the hardware components. Embedded software is a term that is often used to refer to software components designed to run on specific hardware platforms. Embedded software includes may different types and architectural levels of software within a system design, including examples ranging from low-level microcode instructions for a microprocessor to high-level software that run on specialized electro-mechanical devices (such as automobile components, medical devices, controllers, and consumer devices).
Hardware/software co-design or system-level design refers to the process of concurrently forming designs for the hardware and software components of an electronic system. The process of performing hardware/software co-design is considered very challenging for many designers, since it normally requires a multi-disciplinary approach to systems design that must take into account complex effects throughout the different parts of the system. The design of embedded software and systems is particularly seen as a tricky exercise, often needing to consider many acute constraints for a successful design, such as energy consumption, memory space, criticality and safety considerations, and execution time. With many modern systems designs becoming more and more complex, these constraints are causing greater and greater difficulties or the co-design process.
For example, one area of particular difficulty is the process of performing “verification” upon embedded software or electronic designs having both software and hardware components. Verification is usually performed at several stages of the electronic design process to ensure that the electronic design will work for its intended purpose. After a designer has created an initial set of designs, the designer then tests and optimizes the design using a set of EDA testing and analysis tools. At the logical level, simulation and formal verification are used to test the IC design. At the physical implementation level, common testing and optimization steps include extraction, verification, and compaction.
Conventionally, the process to perform co-verification of a systems level or embedded design is viewed as a very difficult and complicated process. In fact, this task is traditionally so difficult to perform that designers often wait to perform co-verification until after prototype hardware is available, e.g., by using circuit emulators or programmable hardware. One significant problem with this approach is that verification results can only be obtained very late in the design process, after many or all of the low-level design details has been completed. At a late stage of the design process, it would be significantly more onerous and expensive to correct any identified problems as compared to correction of problems at much earlier stages of the design process. Another significant problem is the high cost of producing hardware prototypes. Yet another problem is the long turn-around time that is needed to create and implement physical prototypes.
One possible approach that can be taken to address these problems is to perform simulation or formal verification upon the mixed hardware/software systems design. To perform simulation or formal verification, the simulation/verification tool must be able to access a model of the system being simulated/verified. A co-design finite state machine (CFSM) of a mixed hardware/software design can be used to create models or automata that is then simulated or formally verified.
A significant problem with the conventional CFSMs is that they can only be used to model designs at a very high levels of abstraction. To the extent a conventional CFSM is used to model both hardware and software, there are no effective mechanisms to model the lower-level interactions between the two sets of components, e.g., the effects of the software model upon specific registers within hardware. Since complex interactions cannot be adequately modeled, the conventional CFSM cannot be used to flexibly handle the different abstraction levels of detailed systems verifications, particularly designs at lower levels of design abstractions.
Therefore, there is a need for a method and system that allows effective verification of embedded software and/or co-verification of designs having both hardware and software components.